I'm going to think about this one a little. While I want to have CI for Edge, I want to make sure this doesn't make it harder for users to use circle ci themselves.

For example if someone scraps this file and starts over in their repo, what happens with git conflicts? I think git does the right thing (oh, you deleted it back their, so discard conflicts on this file). But I want to make sure.

Ideally this would be something that users could build upon. For example, I love the aggregate deps.edn cache, that's a great thing to reuse! Although, it doesn't do clj for all those deps.edn files, so the .m2 folder will probably need some additional population first.

For example if someone scraps this file and starts over in their repo, what happens with git conflicts? I think git does the right thing (oh, you deleted it back their, so discard conflicts on this file). But I want to make sure.

This is a good point, I hadn't considered this.

Although, it doesn't do clj for all those deps.edn files, so the .m2 folder will probably need some additional population first.

My approach in the past when using Leiningen with CI testing has been to just let the test runners populate the ~/.m2 cache. The boot time to download the dependencies was sometimes quite slow, and often there were dynamic dependencies added after the fact anyway.

Using clj, you don't have as much boot time, so it should be fine to download the dependencies in a separate step. However we still add eftest as a dynamic dependency in the script. I'm not sure how much it buys you pre-downloading the artifacts, but I don't really mind either way.